IP networks enable broadcasting of conversational data (Voice Over IP, Content Sharing, Presence, Instant Messaging, etc.).
The designation H.323 covers a set of protocols for transmission of voice, image and data over IP, as explained in the on-line encyclopedia Wikipedia. These protocols were developed by the ITU-T. They can be grouped together into three categories: signaling, codec (coder-decoder) negotiation, and information transport.
The SIP is defined by the IETF in the document RFC 3261. This protocol makes it possible to set up, modify and terminate multimedia sessions in a network using the Internet Protocol. The SIP also allows event notification procedures and sending information outside the context of a session. It is widely used for instant messaging service commands. Thus in an SIP environment there exist different types of calls such as session set-up requests and requests exchanged outside of any dialogue.
These sophisticated session control protocols make use, in particular, of signaling messages, which are messages enabling a terminal to request a connection with another terminal, and messages signaling that a telephone line is busy, or that the called telephone is ringing, or that the telephone is connected to the network and may be contacted in such or such a manner.
The invention relates particularly (but not exclusively) to IP Multimedia Subsystem (IMS) infrastructures. The IMS is defined by the standards bodies 3GPP (3rd Generation Partnership Project) and TISPAN (Telecommunications and Internet Converged Services and Protocols for Advanced Networking). It is a network architecture introduced by the 3GPP for mobile networks, and then adopted by TISPAN for fixed networks. This architecture enables dynamic setting up and control of multimedia sessions between two clients and reservation of resources at the level of the multimedia stream transport network. It also manages the interaction of services. At present the IMS allows access to telephone, videophone, presence, and instant messaging services.
When a user wishes to obtain the benefit of services offered by an IP network such as those described above, they send network signaling messages that may in particular include various types of request.
First, the user terminals must register with the network. If the network is unable to link this registration and a previous registration (for example following a network fault or the terminal being switched off for longer than a predetermined value), the registration is considered as being an initial registration. After an initial registration, the user terminals must periodically send the network a request to confirm that they wish to maintain their registration.
Moreover, if the network uses the Session Initiation Protocol, user terminals may subscribe to services by sending a corresponding request. This service may be an event notification service: for example, if the user has a voicebox on the network, their terminal may subscribe to a message posting notification service, i.e. it may request to be informed each time that a message is placed in the voicebox; the user terminal may also request to be notified of its registration status; it may equally subscribe to a presence notification service enabling it to receive information published by another user that it has designated, and so on.
Following the initial subscription request, the terminal must periodically send the network a request to renew its subscription.
The various states of the terminal-network system requiring periodic refreshing are commonly referred to as “soft-states”. The applicable standards require the terminals to include timers enabling them to send these refresh requests (registration or subscription refresh) automatically.
A terminal is registered with the network core. This registration is maintained only for a predetermined registration lease duration, commonly referred to as “Core_expires”, that is represented below for convenience using the letter B; by way of example, above-mentioned document RFC 3261 recommends that B has a value equal to 3600 seconds. In other words, if the network core has received an initial registration request or a registration refresh request from a terminal at an instant t0, then in order to ensure that the registration of the terminal is maintained, it is essential for the network core subsequently to receive a registration refresh request at an instant t1 such that t1−t0≦B.
More precisely, when a terminal sends an initial registration request to the network, the request is initially received by access equipment that relays it towards the network core. If the network core accepts the registration, it responds to the access equipment with a registration confirmation message that specifies the duration of the above-mentioned registration lease B=Core_expires. Thereafter, the access equipment sends a registration confirmation message to the terminal, which message specifies a certain registration refresh period to the terminal.
It should be observed that this registration refresh period specified to the terminal, commonly referred to as “Access_expires” and referred to below for convenience by the letter P, is not always equal to the above-mentioned period B=Core-expires. For various technical reasons, the access equipment may need to receive refresh requests that are more frequent, such that the refresh period P specified by said access equipment satisfies P<B. This is referred to as “registration caching”. By way of example, in certain present networks, a value of P is used that is equal to 1450 seconds. Under such circumstances, the access equipment does not necessarily relay all of the registration refresh requests that it receives from the terminal to the network core: if the time that has elapsed between the instant when it receives a registration refresh request and the instant when it most recently relayed a registration request from the terminal is short compared with B, it may respond to the terminal by confirming its registration thereto and specifying a new said period P, but without relaying the request to the network core.
Finally, terminals are usually programmed so that when a terminal has a registration refresh period P specified thereto, it responds by applying an actual registration refresh period, written below with the letter Q, that has a value that is selected to be shorter than P, by way of precaution. In this respect, various ways of programming terminals are known; for example, the following are to be found:
Q=P/2; or
Q=P−600 seconds; or indeed
Q=P−a few seconds
(regardless of the value of P).
After being initially registered, a terminal may, as explained above, subscribe to certain services (for example a message posting notification, presence notification, or registration status notification service). The initial subscription requests are sent either automatically just after initial registration or following user action via the interface of the terminal. For each subscription (initial subscription or subscription refresh), the network informs the terminal of the refresh period required by the network operator for that subscription. In the document RFC 3265, the maximum subscription refresh period used by the core network is defined with reference to the “event-package” part of the document defining the subscription type; for subscribing to the message posting notification service, for example, the document RFC 3842 specifies a refresh period from a few hours to a few days (see under “event-package message summary”).
In this context, during normal operation of the network, the network receives initial registration and initial subscription requests and also receives registration and subscription refresh requests as and when network users connect and then renew their registrations and their subscriptions after the provided respective refresh periods. The processing capacity of the nodes of the network is obviously intended to accommodate the corresponding request frequency, in particular as a function of the usual number of network users. In many circumstances, and in particular with so-called “always-on” networks and services, in normal operation, the reconnection rate, and thus the initial rate of registration and subscription, is particularly low.
However, particular problems arise in this situation in the event of a partial or complete fault of the network.
When a fault occurs in the network and users observe or assume that their registration has been lost because of the fault, then the terminals of those users enter a particular mode of operation known as “registration recovery mode” in which the terminals seek to perform an initial registration, which is indeed usually followed by one or more initial subscriptions. The attempted initial registration may result from a user action on the terminal's interface, or it may be performed automatically by the terminal as a function of its programming. For example, the LiveBox terminals from France Telecom are at present programmed to attempt to register every 4 minutes. Thus, the terminals apply a time-out period that usually lies in the range a few tens of seconds to a few minutes, and that is in any event much shorter than the above-mentioned actual registration refresh period Q. This gives rise to an abnormally high rate of registration attempts.
Thus, in the state of the art, while the network restarting, terminals send their respective registration requests in a manner that is slightly offset one relative to another. Throughout a duration that is approximately the mean time-out period, the network therefore needs to accommodate an abnormally high inflow of requests, with this being particularly severe if the fault has lasted a long time. Furthermore, assuming that the network is capable of handling this restart traffic, it will still need to accommodate a new inflow of requests issued by the same terminals at the end of the registration refresh period.
However, the assumption that the network is capable of handling all signaling requests during restarting is often found to be untrue in practice. Each node of the network, as a function of its capacity (which may vary from one node to another), handles the first request that it receives; in so doing, the load level on the node of the network increases rapidly and very often reaches overload. Under such conditions, one or more nodes of the network (in particular in the network core) do not manage to satisfy all requests in time. More precisely, in nodes for which it has not been possible to handle a request:                either the terminals receive a failure response from the network;        or else the terminals do not receive any response in an allotted time (64×T1, i.e. 32 seconds if T1=500 milliseconds (ms) in application of document RFC 3261), and they deduce therefrom that their registration request has failed.These terminals will therefore perform successive registration attempts that are mutually spaced apart by said time-out period until they finally manage to become connected or reconnected (or give up trying . . . ).        
For a given terminal, the time for which the terminal must wait after a network fault before being registered again is therefore on average an increasing function of its time-out period. The expression “on average” refers to the fact that, for a given terminal, this time also depends on the moment at which the terminal attempts to register relative to the moment at which the fault clears. If by chance it attempts to register just after the fault clears, and assuming that the network is not overloaded, it is virtually certain that it will succeed in registering; in contrast, if it attempts to register just before the fault clears, it will have to wait the entire time-out period before attempting again to register.
To summarize, when a fault occurs in known telecommunications systems, the network is observed to saturate and some users have to wait for a long time before they manage to connect or reconnect.